Summary

When array_splice is called on a constant array with only integer keys and a non-constant replacement array, PHPStan incorrectly inferred the result as non-empty-array<int<0, max>, string> instead of non-empty-list<string>. Since array_splice always re-indexes integer keys, the result should be recognized as a list.

Changes

• In src/Type/Constant/ConstantArrayType.php, spliceArray() method:
  • Added $allKeysInteger check before the main loop to determine if the original constant array has only integer keys
  • After building each result variant, if all keys were integers and the result is not already a list, intersect with AccessoryArrayListType to ensure list-ness is preserved
• Added regression test tests/PHPStan/Analyser/nsrt/bug-14472.php with three cases:
  • Constant array with integer keys + non-constant replacement (the reported bug)
  • Constant array with integer keys + list replacement
  • Constant array with string keys (already correct, no change)

Root cause

In ConstantArrayType::spliceArray(), when the replacement array is not a ConstantArrayType, the ConstantArrayTypeBuilder is degraded via degradeToGeneralArray(), and then setOffsetValueType() is called with the replacement's key type (non-null). In the degraded builder path, any non-null key in setOffsetValueType sets $this->isList = TrinaryLogic::createNo(), which causes the list property to be lost.

The fix adds a post-processing step: after the builder produces the result, if the original constant array had only integer keys, AccessoryArrayListType is added to the result. This mirrors the same logic already present in ArrayType::spliceArray() (line 546-548).

Analogous cases probed

• ConstantArrayType::sliceArray() — uses null for auto-increment keys in non-degraded builder, correctly preserves list-ness. No issue.
• IntersectionType::spliceArray() — delegates to each member type including AccessoryArrayListType::spliceArray() which returns $this. No issue.
• AccessoryArrayListType::spliceArray() — returns $this. No issue.
• Sort functions (sort, rsort, usort) — handled in FuncCallHandler by directly constructing list types. No builder degradation involved. No issue.
• ConstantTypeHelper::getTypeFromValue() — has a similar pattern with degradation for large arrays (>256 elements), but affects a much rarer edge case and uses a different code path. Not fixed in this PR.

Test

• tests/PHPStan/Analyser/nsrt/bug-14472.php: NSRT test with assertType calls verifying:
  • array_splice on ['last_name', 'first_name', ...] with non-constant replacement produces non-empty-list<string>
  • array_splice on ['a', 'b', 'c'] with list replacement produces non-empty-list<string>
  • array_splice on string-keyed array preserves exact constant array type (no regression)

Fixes phpstan/phpstan#14472